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Abstract 


This paper examines the performance of the Digital Smart Technologies for Amateur Radio - Digital Data 
mode with various IP and non-IP based protocols. A throughput comparison was performed between IPv4, IPv6, 
the DTN Convergence Layer and the NORM Convergence Layer. The experimental results show that the DTN 
NORM Convergence Layer exhibits better performance than TCP/IP, and appears to perform better over difficult 
radio links. 


I. INTRODUCTION 


The Icom Digital Smart Technologies for Amateur Radio (D-STAR [1]) family of transceivers and 
the use of the D-STAR protocol is becoming more and more an integral part of the toolbox used by 
Amateur Radio operators for emergency communications activities. The D-Star Digital Data (DD) mode 
(in the Icom ID-1 transceiver) is of interest as the radio transceiver presents an ethernet interface, and 
thus any protocol that can be transmitted over ethernet can be sent between any pair of ID-1 transceivers. 

In the event of more than two transceivers operating on a single channel, which is likely in an 
emergency communications scenario, there would likely be a lot of traffic on a channel all in contention 
for the same bandwidth. This would be necessary in the early stages of an incident until normal 
communications links were restored. 

To the best of the authors knowledge, little work has been done to ascertain the impact on the TCP/IP 
suite of protocols (or indeed any others) of operating multiple transceivers on a single channel in this 
type of environment. Previously [2], at the 2009 DCC, some initial results of experiments with DTN 
and IP networking using Icom ID-1 transceivers in Digital Data mode were presented. These results 
were preliminary and not experimentally verified. 

The approach taken was to firstly test the various protocols in a control scenario to get the best 
possible realistic throughput, followed by a real point-to-point link (approx 9kms). The rest of this 
paper is organised as follows: in §2 we briefly explain the D-STAR and DTN concepts, §3 gives an 
overview of the test scenarios, §84 presents our results, §5 our discussion and §6 our conclusions and 
future work. 


II. BACKGROUND 


The authors interest in DTN stems from the potential of DTN to be used to support emergency 
communications activities, especially where multiple different network types converge i.e. AX.25 [3], 
D-STAR and the set of 802.11 standards [4] that make up what is commonly referred to as “WiFi”. 

In this paper we compare the performance of the TCP/IP protocols, TCP [5]-[7], versus two DTN 
Convergence Layer implementations namely TCP-CL [8] and NACK-Orientated Reliable Multicast 
Transport Protocol (NORM) [9]. 
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A. Disruption/delay tolerant networking 


Disruption or Delay Tolerant Networking (DTN), is an approach to computer network architecture 
that seeks to address the technical issues in heterogeneous networks that may lack continuous network 
connectivity or other extreme environments. Some issues to be addressed include large delay for 
transmissions resulting from either physical link properties or extended periods of network partitioning, 
routing capable of operating efficiently with frequently-disconnected, pre-scheduled, or opportunistic link 
availability, high per-link error rates making end-to-end reliability difficult, heterogeneous underlying 
network technologies (including non-IP-based internets). The DTN architecture [10] uses in-network or 
node-level storage to provide an overlay network over various types of network infrastructures. This 
node-level storage allows application messages (bundles in the DTN architecture) to be stored on DTN 
gateways (or nodes) for arbitrary lengths of time, while waiting for a forward path to become available. 
This clearly differs from the IP model where IP packets must be forwarded immediately, or dropped. The 
Delay-Tolerant Networking Research Group (DTNRG)! has a reference implementation of the protocol 
[11] available for experimentation, extension and real-world deployment. See [12] for more information 
on DTNs. 


B. Digital Smart Technologies for Amateur Radio (D-STAR) 


Digital Smart Technologies for Amateur Radio, commonly known as D-STAR, is a digital voice and 
data protocol specification, published in 2001, which was developed as the result of research funded by 
the Japanese government and managed by the Japan Amateur Radio League [13]. The purpose of the 
research was to investigate digital technologies for amateur radio. While there are other digital on-air 
technologies being used by amateurs that have come from other services, D-Star is one of the first 
on-air and packet-based standards to be widely deployed and sold by a major radio manufacturer that 
is designed specifically for amateur service use. 

The D-STAR system supports two types of digital data streams. The Digital Voice (DV) stream used 
for example on 430-440 MHz contains both digitised voice (3600 bps including error correction) and 
digital data (1200 bps). Using a DV radio is like having both a packet link and FM voice operating 
simultaneously. The Digital Data (DD) stream, used only on 1200MHzZz, is entirely data with a bit rate 
of 128k bps. An Ethernet connection is used for high-speed DD D-STAR data. 

This work is solely concerned with the Digital Data mode available on the Icom ID-1 transciever. 


Ill. EXPERIMENTAL NETWORK 


Figures | shows the experimental network used to measure the system performance. Each node 
in the network consisted of an Icom ID-1 transceiver and a Linux PC. For D-Star testing, both the 
DTN reference implementations TCP Convergence Layer (TCP-CL) and the NORM Convergence Layer 
(NORM-CL) were used to investigate DTN performance. NORM was chosen for examination as previous 
research [14] suggests that NORM would be suited for use in networks that are bandwidth constrained, 
or networks that suffer from high levels of packet loss. 

Two separate network configurations were examined. 

¢ Control - two radios in close proximity for maximum signal strength/minimum interference. 

e Point-to-Point - 9km link. 

The Control configuration was investigated with both radios operating indoors in an ideal environment. 
In both configurations, all routing was configured statically, to avoid routing broadcasts interfering with 
transfer times. 

Figure 1 was configured with Icom ID-1 transcievers at the location of EI7IG, and EI8JA. The aerial 
at EI7IGs location was a Diamond X-5000 with a Diamond X-7000 at EI8JAs location. Under calm 


'www.dtnrg.org 


135 


Hal f-duplex radio channe 


D-Star 
DESTINATION 


SOURCE 


Fig. 1. 9km point-to-point link, not quite line-of-sight 


wind conditions, 2 bars of “signal” were visible on the display, with the occasional flicker of a third 
bar. 

The following tests were done in each network configuration: 

e IPv4 TCP 

e IPv6 TCP 

e« TCP Convergence Layer 

e NORM Convergence Layer 

Each test was repeated 25 times to get an average throughput figure for that particular protocol. Care 
was taken to run the tests under similar atmospheric conditions. The weather station” situated at EI8JA’s 
location was regularly monitored for wind speed. The iperf [15] tool was used to test TCP on both IPv4 
and IPv6. The results for IPv4 were generated with the following command run in a loop 25 times: 


iperf -c 192.168.254.2 -t 600 -i 10 


Similiarly for IPv6: 
iperf -V -c fecO::2 -t 600 -i 10 
Where /92.168.254.2 and fec0::2 are the IPv4 and IPv6 addresses of the destination node (192. 168.254. 1 


and fec0::1 are the source addresses). 
The result was a report, with a summary line similar to the following: 


[ 3] 0.0-601.3 sec 4.90 MBytes 68.3 Kbits/sec 


To test the DIN Convergence Layers the dtnsend utility was used to send a 6MB file across the link. 
dtnsend was configured to ask for a delivery receipt, and the result of this was a report similar to the 
following: 


got 33 byte report from [dtn://itx2.dtn]: time=639445.0 ms 


From these results a spreadsheet was compiled and all results were then converted into bytes per 
second 


IV. RESULTS 
NORM was initially configured with a fixed transmission rate of 128kbps. After the initial testing was 
complete, through experimentation, it was found that configuring NORM for a rate of 84kbps seemed 


*http://aprs.fi/weather/a/EI2WRC 
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TABLE I 
D-STAR PERFORMANCE - CONTROL CONFIGURATION 


Protocol Min (bytes/sec) | Max (bytes/sec) | Average (bytes/sec) 
IPv4 8502.90 8649.84 8576.03 

IPv6 5043.07 8372.66 7693.93 
TCP-CL 8108.23 8306.87 8242.80 
NORM-CL (128) 7850.68 8267.08 8106.88 
NORM-CL (84) 9818.84 9926.74 9877.13 


to provide the maximum throughput. 


TABLE II 
D-STAR PERFORMANCE ON POINT-TO-POINT LINK 


Protocol Min (bytes/sec) | Max (bytes/sec) | Average (bytes/sec) 
IPv4 85.69 3449.95 1117.19 

IPv6 OT 4268.80 1732.88 
TCP-CL 1904.04 7668.61 5527.75 
NORM-CL (128) 4440.96 8014.53 6490.19 
NORM-CL (84)* 1906.23 8632.93 4362.66 


72 test runs timed out before they could complete; *High winds were experienced on this run — see section V 


V. DISCUSSION 


Looking at Table I, results seem in line with general expectations. IPv6 achieved less throughput than 
IPv4, as it has a larger packet header size. The DTN TCP-CL average throughput is between IPv6 and 
IPv4, i.e. the DTN overhead on an IPv4 packet is less than IPv6 Header overhead. The NORM result 
is interesting, setting the transmission rate at 84kbps results in an average that is approximately 1300 
bytes/sec faster than the next best which is IPv4. 

Two of the IPv6 test runs were unable to even start. Both times the TCP connect was sent, no reply 
was received, this resulted in the connection timing out eventually. All other protocols completed 25 
test runs. 

Initially, it was planned to include a scenario with a single hop and, also, a node generating interfering 
traffic. However, when testing began on the point-to-point link it was found that it was far more difficult 
to achieve a usable, solid connection than prior experience had suggested. Also, a row of trees had grown 
into the fresnel zone and it was not (legally) possible to have them cut back. This coincided with a 
period of windy weather, which meant days testing could be completed were few and far between, as 
the X-7000, being a large vertical antenna, tended to sway in the breeze. Changing to a beam antenna 
did not help the situation. 

Looking at Table II, moving to the “real-world” is even more interesting. The RF path was, in a word, 
hostile, and this can be seen in the results. IPv4 and IPv6 average throughput reduced significantly. IPv6 
has a higher average of the pair, but we are of the opinion that this was due to weather conditions favoring 
the IPv6 test run (the order of tests was generally IPv4, IPv6, TCP-CL, NORM-CL). A NORM test run 
with the rate set to 84kbps was run, however wind conditions at the time were far far higher than the 
others so an attempt was made to stop the script. The TCP session was unable to deal with the poor 
RF connection and it eventually timed out. The following morning, after the test run completed, it was 
still impossible to log into the machine remotely over the RF connection to retrieve the logfile. These 
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results really are a testament to how robust the NORM protocol is for data transfer, under conditions 
where TCP is unusable. 


VI. CONCLUSION 


From previous work, we had seen the DIN NORM Convergence Layer showed signs of being more 
efficient than the TCP/IP protocol over DD mode D-Star radio links. A 15% improvement using NORM 
over [Pv4 is significant enough, what we did not expect to see was a dramatic difference between the 
robustness of NORM vs TCP. 

Looking back at the results, the TCP tests they appear to be broadly in line with what would be 
expected, in that the throughput is best in IPv4, then TCP-CL, then IPv6. On Icom ID-1 transceivers, 
NORM appears to have a optimal transmission rate of 84kbps which gives the 15% improvement over 
IPv4. The robustness of NORM was not something we expected, this became apparent due to the 
difficult RF path between both nodes and is worth highlighting. The measurements taken provide an 
illustration that, even without considering robustness in the face of disruption, the ubiquitous TCP/IP 
protocol is not always the best choice. 

Future work will include re-location of one of the two point-to-point stations for a more reliable 
connection. With that in place work can be done on multi-hop transfers and whether DTN performs 
better in this scenario. At this time the impact and stability of routing protocols in this environment can 
also be evaluated. 
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